Skip to content

Various fixes and improvements to hash2curve #1813

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 23, 2025

Conversation

daxpedda
Copy link
Contributor

@daxpedda daxpedda commented Apr 11, 2025

This was mainly to fix a bug in handling large DSTs for expand_message_xof.

  • ExpandMsg::expand_message()s len_in_bytes parameter is now a NonZero, moving one run-time error to the type system.
  • In tandem FromOkm::Length now requires typenum::NonZero.
  • Added generic K parameter to ExpandMsg implementers.
    • ExpandMsgXmd only uses it to follow constraints set by the specification more closely. See https://www.rfc-editor.org/rfc/rfc9380.html#section-5.3.1-2.1.
    • More importantly, ExpandMsgXof, requires K to calculate the size for the computed DST if the given DST is larger than 255 bytes. This was previously not implemented correctly in that it always used a 32-byte long computed DST.
  • Added type K to the GroupDigest trait. This allows blanket implementations to use the right K for ExpandMsgXmd and ExpandMsgXof.
  • Added HashMarker to the constraints of HashT for ExpandMsgXof.
  • Moved documentation from ExpandMsg trait implementations to the actual type and added links to the specification.

Cc @mikelodder7.

@daxpedda daxpedda force-pushed the hash2curve-improvement2 branch from 3c73c3d to 5f3658c Compare April 11, 2025 19:49
@daxpedda daxpedda force-pushed the hash2curve-improvement2 branch from edc77d1 to 1f2fd8b Compare April 17, 2025 14:05
@daxpedda daxpedda force-pushed the hash2curve-improvement2 branch from 1f2fd8b to 2f0bf9b Compare April 17, 2025 14:06
@daxpedda
Copy link
Contributor Author

daxpedda commented Apr 17, 2025

After discussions in #1816 and the implementation in #1820 it made more sense to represent everything in bytes and not in bits. Especially because there doesn't seem to be use-case requiring bit-level accuracy (because everything is divisible by 8).

@tarcieri tarcieri merged commit 5d3e031 into RustCrypto:master Apr 23, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants